1. Field of the Invention
The present invention relates to controlling assets such as digital content in a multimedia application environment, and more particularly, to a cyclic referencing management method and apparatus, a parsing method and apparatus, and a computer readable recording medium storing a program to implement the methods.
2. Description of the Related Art
Recently, media such as digital still images, video, digital audio, and text have been processed and reproduced by using a personal computer (PC). Also, as apparatuses generating these media, for example, digital cameras, digital camcorders, digital audio players (MP3, WMA), are increasingly widely used, a variety of types of digital content are massively generated.
However, in order to manage the content, that is, multimedia data, which are massively generated, file based experiences are requested to users, and if thus managed data, to which attributes, such as a data reproduction order or method, are given, is reproduced in an apparatus other than a PC, the attribute data given in the PC is lost and only original data is transferred. That is, interoperability of data and data attributes among consumer electronic products, PCs, and digital content generating apparatuses is very weak at present. Examples of weakness of interoperability will now be explained.
FIG. 1 is a reference diagram explaining the concept of MusicPhotoVideo (MPV) according to a conventional technology.
Referring to FIG. 1, by using a digital camera 10, a photo or video clip is generated, the generated photo or video clip is moved to a PC 11, works such as edition are performed, and the worked content are burned on an optical recording medium such as a CD-R/Video-CD, and a DVD-R/+R. The thus burned optical recording medium can reproduce the content in a DVD player 12 or a TV 13.
Also, the content worked in the PC can be transferred to a printer 14 to be printed, and to an online medium 15.
Thus, by using a digital camera, a photo is captured, and attribute data, such as a slide show order or a time interval between photos determined when a slide show function is used to confirm the capture photos in the digital camera, or relations between the captured photos determined when a panorama function is used, is stored together with the original data. If this digital camera is connected to a TV through an audio/video (AV) cable and an image is transmitted to the TV, content with each attribute expressed can be viewed by a user. However, if the digital camera is connected to a PC through a universal serial bus (USB) cable, only the original data is transmitted to the computer and all the attached attributes are lost.
This is because the digital camera and the PC have information structures different to each other. As shown in the above example, the attribute data stored in the digital camera, that is, metadata, has no interoperability with the PC. In order to compensate these data between digital apparatuses for weak interoperability, a standard referred to as MusicPhotoVideo (MPV) has been being prepared. That is, the MPV is a standard to further ease expression, exchange, processing, and reproduction of metadata such as digital music, photo, and video in consumer electronics (CE) apparatuses and IT apparatuses. The MPV standard, which is currently being prepared by Optical Storage Technology Association (OSTA), defines manifest, metadata, and practice to process and reproduce sets of content, such as digital photos, video, and audio, stored in a storage medium such as an optical disk, a memory card, a computer hard disk, or exchanged according to Internet protocols. The manifest is an independent extensible markup language (XML) document file and is obtained by grouping all MPV elements.
The MPV is generally broken down into two parts: MPV core specification (MPV Core-Spec.) and Profile. The MPV Core includes three basic elements: collection, metadata, and identifier. The collection includes a manifest as a root member, an album, marked assets (MarkedAsset), and an asset list (AssetList). An asset is a basic unit of content processed by the MPV and there are two types of assets: a simple media asset such as digital photos, video, digital audio, and documents, etc., and a composite media asset such as digital photos+digital audio, digital still multi-shot sequences, digital still panorama sequences, etc. Based on the content recorded in an MPV file having this structure, MPV software controls such that an asset is read and reproduced. That is, the MPV file is placed between MPV software and data referred to as an asset, and plays a linking role. Accordingly, the MPV file can be regarded as a file system in a higher level operating similarly to the conventional file system.
The asset that is a basic unit of content processed in the MPV will now be explained in more detail with reference to FIGS. 2 and 3.
FIG. 2 is a diagram showing an example of MPV simple assets according to the conventional technology. Simple assets correspond to physical storage entities. As simple assets, there are a still 21, a video 22, an audio 23, a text 24, a print 25, a document 26, and a manifest link (ManifestLink) 27.
FIG. 3 is a diagram showing an example of MPV composite assets according to the conventional technology. Composite assets are meaningful groups of media assets. These composite assets correspond to ordinary capture modes of a digital camera.
As composite assets, there are a still with audio (StillWithAudio) 31, a still multi-shot sequence (StillMultishotSequence) 32, a still panorama sequence (StillPanoramaSequence) 33, a Par 34, and a Seq 35.
Among these, the Par 34 or Seq 35 permits arbitrary expression of media assets different to each other in types. That is, while other composite assets are fixed in that simple assets contained in respective composite assets are predefined, simple assets contained in the Par or Seq are not fixed such that simple assets can be arbitrarily combined.
The Par defines a composite asset when a set of assets are generated in synchronization with each other. Referring to FIG. 3, it can be seen that Par 34 is formed with a group of assets, which are arranged to be parallel. The Seq defines a composite asset when a set of assets are generated in a predetermined order. Referring to FIG. 3, it can be seen that Seq 35 is formed with a group of assets, which are arranged in a predetermined order.
The usage of the Seq will now be explained.
FIG. 4A is an example of an MPV file explaining a usage example of <mpv:Seq> according to the conventional technology.
Referring to FIG. 4A, it can be seen that a manifest 1 is at the top level that is the largest in an MPV file, and an asset list 40 is at a level immediately below the top level.
Then, the lower levels of the asset list 40 include <mpv:Seq> 41 whose identifier (mpv:id) is “seq001”, <mpv:Still> 42 whose identifier is “still001”, <mpv:Still> 43 whose identifier is “still002”, <mpv:Still> 44 whose identifier is “still003”, <mpv:Still> 45 whose identifier is “still004”, <mpv:StillWithAudio> 46 whose identifier is “sa001”, <mpv:Audio> 47 whose identifier is “audio001”, <mpv:Audio> 48 whose identifier is “audio002”, and <mpv:Audio> 49 whose identifier is “audio003”.
Thus, the assets 41 through 49 at the levels lower than the asset list 40 are child assets of the asset list 40, and reversely, the asset list 40 is the parent asset of the child assets 41 through 49.
Among these child assets, <mpv:Seq> 41 and <mpv:StillWithAudio> 46 are composite assets and the remaining assets, <mpv:Still> and <mpv:Audio>, are simple assets.
Simple assets each have a LastURL indicating the location of content for referencing the asset. For example, a still asset whose identifier (ID) is “still001” expresses “images/still01.jpg”, as the LastURL indicating the location of still001 content.
In the composite assets, <mpv:Seq> 41 internally has 6 child assets.
That is, it can be seen that the first child asset of <mpv:Seq>41 refers to an audio whose ID is “audio001”. The second child asset refers to a still whose ID is “still001”, the third child asset refers to an audio whose ID is “audio002”, the fourth child asset refers to a StillWithAudio whose ID is “sa001”, the fifth child asset refers to a still whose ID is “still002”, and the sixth child asset refers to a still whose ID is “still003”.
In the composite assets, the StillWithAudio 46 internally has 2 child assets.
The first child asset refers to a still whose ID is “still004”, and the second child asset refers to an audio whose ID is “audio003”.
In the composite assets as described above, it can be seen that the StillWithAudio has only a still and an audio as assets, as shown in its name, while <mpv:Seq> can have any assets as its child assets.
Thus, <mpv:Seq> can have any type of reference assets with an ending of Ref, as in, for example, mpv:StillRef, and mpv:AudioRef. Accordingly, it is very complex to extract information from this asset. For example, in order to obtain actual information of <mpv:Still> embedded in <mpv:StillWithAudioRef> assigned by <mpv:Seq>, the following steps are required:
1. In order to obtain <mpv:StillWithAudioRef> whose mpv:idRef is “sa001”, parsing <mpv:Seq> whose mpv:id is “seq001” is performed,
2. in order to obtain <mpv:StillRef>, parsing <mpv:StillWithAudio> whose mpv:id is “sa001” is performed, and
3. mpv:idRef attribute of <mpv:StillRef> in <mpv:StillWithAudio> is obtained and <mpv:Still> whose mpv:id is “still004” is found.
FIG. 4B is a diagram of a tree structure explaining the structure of the MPV file shown in FIG. 4A.
Referring to FIG. 4B, an AssetList 40 is below a manifest 1, and 9 child assets 41 through 49 are below the AssetList 40.
Each child asset of <mpv:Seq> 41 refers to a child asset of the AssetList 40.
This structure is an ordinary form of using <mpv:Seq> that is a composite asset.
FIG. 5A is an example of an MPV file explaining another usage example of <mpv:Seq> according to the conventional technology.
Referring to FIG. 5A, an AssetList has 5 child assets.
The first child asset 51 is <mpv:Seq> whose ID is “seq001” and which has a child asset referring to an asset whose ID is “seq002”.
The second child asset 52 is <mpv:Seq> whose ID is “seq002” and which has a child asset referring to an asset whose ID is “still001”, and a child asset referring to an asset whose ID is “seq003”.
The third child asset 53 is <mpv:Seq> whose ID is “seq003” and which has a child asset referring to an asset whose ID is “still002”.
The fourth child asset 54 is a still asset whose ID is “still001”.
The fifth child asset 55 is a still asset whose ID is “still002”.
FIG. 5B is a diagram of a tree structure explaining the structure of the MPV file shown in FIG. 5A.
Referring to FIG. 5B, <mpv:Seq> 51 that is the first child asset of the AssetList refers to <mpv:Seq> 52 that is the second child asset, and <mpv:Seq> 52 that is the second child asset refers to <mpv:Seq> 53 that is the third child asset. Also, <mpv:Seq> 53 that is the third child asset refers to “still002” that is a simple asset.
Though <mpv:Seq> continuously refers to another <mpv:Seq>, an asset that is finally referred to is “still002” that is a simple asset. Accordingly, a problem such as cyclic reference does not occur.
Thus, it can be seen that a composite asset like <mpv:Seq> or <mpv:Par> is made to have a plurality of primary assets as children. Though this composite structure of a composite asset has an advantage that a greater variety of reproduction scenarios can be implemented, there may occur a variety of problems due to many children. One of these problems is “cyclic referencing”, which will now be explained with reference to FIGS. 6A and 6B.
FIG. 6A is an example of an MPV file explaining a case where cyclic referencing occurs due to use of <mpv:Seq> according to the conventional technology.
Referring to FIG. 6A, an AssetList has 3 child assets that are all <mpv:Seq>.
The first child asset 61 is <mpv:Seq> whose ID is “seq001”, and refers to an asset whose ID is “seq002”.
The second child asset 62 is <mpv:Seq> whose ID is “seq002” and refers to an asset whose ID is “seq003”.
The third child asset 63 is <mpv:Seq> whose ID is “seq003” and refers to an asset whose ID is “seq001”.
In this situation, a cyclic referencing problem occurs. That is, since the third child asset from the top again refers to the first child asset, these 3 child assets are entering an infinite loop.
FIG. 6B is a diagram of a tree structure explaining the structure of the MPV file shown in FIG. 6A.
Referring to FIG. 6B, child asset seq001 61 refers to child asset seq002 62, child asset seq002 62 refers to child asset seq003 63, and child asset seq003 63 refers to child asset seq001 61. Accordingly, it can be seen that a loop is generated among seq001, seq002, and seq003, which generates a cyclic referencing problem in which getting out of the loop is impossible.
FIG. 7 is another example of an MPV file explaining a case where cyclic referencing occurs due to use of <mpv:Seq> according to the conventional technology.
Referring to FIG. 7, an AssetList has a child asset, <mpv:Seq> 71, whose ID is “seq0000”. The child asset 71 has a child asset, <mpv:SeqRef>, which refers to an asset whose ID is “seq0000”. Since the parent asset 71 and the child asset 72 refer to each other, an infinite loop occurs between the two and the system may operate as if it halts. Accordingly, a cyclic referencing problem occurs.
However, in the conventional technology, if a cyclic referencing problem occurs while an MPV parser parses an MPV file, the parser reports to the application that the MPV data is incorrect, or the system operates incorrectly as if it halts. Accordingly, data contained in the MPV file cannot be used any more.